41 research outputs found

    Évaluation des risques et de la complexité sur le contexte de la migration linguistique

    Get PDF
    International audienceLanguage Migration is a highly risky and complex process. Many authors have provided different ways to tackle down the problem, but it still not completely resolved, even-more it is considered almost impossible on many circumstances. Despite the approaches and solutions available, no work has been done on measuring the risks and complexity of a migration process based on the technological gap. In this article we contribute a first iteration on Language Migration complexity metrics, we apply and interpret metrics on an industrial project. We end the article with a discussion and proposing future works.La migration de langage est un processus hautement risqué et complexe. De nombreux auteurs ont proposé différentes manières d'aborder le problème, mais il n'est toujours pas complètement résolu, encore plus, il est considéré comme presque impossible dans de nombreuses circonstances. Malgré les approches et les solutions disponibles, aucun travail n'a été fait pour mesurer les risques et la complexité d'un processus de migration basé sur le décalage technologique. Dans cet article, nous contribuons à une première itération sur les métriques de complexité de la migration linguistique, nous appliquons et interprétons des métriques sur un projet industriel. Nous terminons l'article par une discussion et proposons des travaux futurs

    Reporting Context Aware Partial Translation engine based on immediate and delayed Rule application

    Get PDF
    Language migration has been the driver of many efforts resulting in multiple solutions and strategies. One of the most popular approaches for dealing with it is source code translation: it proposes to translate the source code of an application to a target language. For doing so it leverages a set of translation rules based on the grammatical constructions provided by the source and target languages. However, we notice that even when most of the literature acknowledges translating implies migrating the runtime, libraries and the Software Development Kit (SDK), none of them proposes a systematic way to solve this problem. Along with this, we notice that there are many proposals to shift the paradigm from procedural to object-oriented programming based on how to propose classes automatically. But we found nothing on how to translate the expressions that use functions into expressions that use methods. In the context of migration from Microsoft Access (MS Access) to web technologies, these two lacks threaten seriously any attempt to produce even a compilable version of the code on the target technology. This article proposes a translation engine that split the translation process into two phases. A phase of language translation, and a phase of adaptation to the target environment. The first phase is in charge of producing declarations, and the second one is in charge of adapting the usage of this declaration to fit the translated version of our artefacts. We argue that enabling to adapt the code to fit the translated version of our artefacts allows the definition of simple adapting rules able to deal with a large share of both problems: (i) runtime, libraries and the Software Development Kit (SDK), and (ii) simple paradigm shift. This article presents some basic adapting rules and validates our approach by translating a battery of simple tests that feature the usage of a carefully chosen set of features

    Alce: Predicting Software Migration

    Get PDF
    The constant apparition of new technologies challenging and disrupting the way to develop software pushes dayby-day software migration to become more and more common. Despite the "normality" of software migration, it is a problem that had ruined more than one company in the past. It is no wonder that different methods to migrate software have been the driver of many efforts and the centre of many discussions for years, resulting in multiple solutions and strategies to accomplish the desired migration. However, there is a lack of efforts on how software reengineering can be used to assess the process of planning by measuring and predicting the cost of a migration. In this article, we present Alce, a software migration assessment and prediction tool under development in the context of a collaboration with Berger-Levrault, for migrating Microsoft Access applications. We present a simple use case that represents most of the usages we had given to the tool during the analysis and reporting of two different applications to be migrated, to assess the extremely hard task of planning a software migration. We present as well a second use for task definition and prioritisation in the process of library migration. We discuss future features based on the interaction with one of the project managers, and finally, we discuss the lack of software reengineering tools usage in the context of software migration

    Analysing Microsoft Access Projects: Building a model in a Partially Observable Domain

    Get PDF
    International audienceDue to the technology evolution, every IT Company migrates their software systems at least once. Reengineering tools build system models which are used for running software analysis. These models are traditionally built from source code analysis and information accessible by data extractors (that we call such information observable). In this article we present the case of Microsoft Access projects and how this kind of project is partially observable due to proprietary storing formats. We propose a novel approach for building models that allows us to overcome this problem by reverse engineering the development environment runtime through the usage of Microsoft COM interface. We validate our approach and implementation by fully replicating 10 projects, 8 of them industrial, based only on our model information. We measure the repli-cation performance by measuring the errors during the process and completeness of the product. We measure the replication error, by tracking replication operations. We used the scope and completeness measure to enact this error. Completeness is measured by the instrumentation of a simple and scoped diff based on a third source of information. We present extensive results and interpretations. We discuss the threats to validity, the possibility of other approaches and the technological restrictions of our solution

    Appendix To Software Migration: A Theoretical Framework A Grounded Theory approach on Systematic Literature Review

    Get PDF
    Software migration has been a research subject for a long time. Major research and industrial implementations have been conducted, shaping not only the techniques available nowadays, but also a good part of Software evolution jargon. To understand systematically the literature and grasp the major concepts is challenging and time consuming. Even more, research evolves, and it does based on the assumption that there is a single meaning that we all share redounding in the pollution of words with multiple and many times opposite meanings. In our quest to understand, share and contribute scientifically in this domain, we recognise this situation as a problem. To tackle down this problem we propose a taxonomy on the subject as a theoretical framework grounded on a systematic literature review. In this study we contribute a bottom-up taxonomy that links from the object of a migration t

    Challenges for Layout Validation: Lessons Learned

    Get PDF
    International audienceCompanies are migrating their software systems. The migration process contemplates many steps, UI migration is one of them. To validate the UI migration, most existing approaches rely on visual structure (DOM) comparison. However, in previous work, we experimented such validation and reported that it is not sufficient to ensure a result that is equivalent or even identical to the visual structure of the interface to be migrated. Indeed, two similar DOM may be rendered completely differently. So, we decide to focus on the layout migration validation. We propose a first visual comparison approach for migrated layout validation and experiment it on an industrial case. Hence, from this first experiment and already existing studies on image comparison field, we highlight challenges for layout comparison. For each challenge, we propose possible solutions, and we detail the three main features we need to create a good layout validation approach

    Migrating GWT to Angular 6 using MDE

    Get PDF
    International audienceIn the context of a collaboration with Berger-Levrault, a major IT company, we are working on the migration of a GWT application to Angular. We focus on the GUI aspect of this migration which, even if both are web frameworks, is made difficult because they use different programming languages (Java for one, Typescript for the other) and different organization schemas (e.g. different XML files). Moreover, the new application must mimic closely the visual aspect of the old one so that the users of the application are not disturbed. We propose an approach in three steps that uses a meta-model to represent the GUI at a high abstraction level. We evaluated this approach on an application comprising 470 Java (GWT) classes representing 56 screens. We are able to model all the web pages of the application and 93% of the wid-gets they contain, and we successfully migrated (i.e., the result is visually equal to the original) 26 out of 39 pages (66%). We give examples of the migrated pages, both successful and not

    GUI Migration using MDE from GWT to Angular 6: An Industrial Case

    Get PDF
    International audienceDuring the evolution of an application, it happens that developers must change the programming language. In the context of a collaboration with Berger-Levrault, a major IT company, we are working on the migration of a GWT application to Angular. We focus on the GUI aspect of this migration which, even if both frameworks are web Graphical User Interface (GUI) frameworks, is made difficult because they use different programming languages and different organization schema. Such migration is complicated by the fact that the new application must be able to mimic closely the visual aspect of the old one so that the users of the application are not disrupted. We propose an approach in four steps that uses a meta-model to represent the GUI at a high abstraction level. We evaluated this approach on an application comprising 470 Java (GWT) classes representing 56 pages. We are able to model all the web pages of the application and 93% of the widgets they contain, and we successfully migrated 26 out of 39 pages (66%). We give examples of the migrated pages, both successful and not

    Make reusable components extracted an object-oriented implementation

    No full text
    La réutilisation est l’un des principaux objectifs de l’ingénierie logicielle. De nombreux concepts et mécanismes associés ont été proposés pour promouvoir la réutilisation des fonctionnalités offertes par le logiciel. L’ingénierie logicielle à base de composants (CBSE) est l’une des plus importantes approches qui ont été proposées pour augmenter la réutilisation des logiciels.Ainsi, plusieurs travaux ont été réalisés afin de restructurer les systèmes existants en systèmes à base de composants. Néanmoins, presque toutes les approches proposées visent plus l’identification des composants que l’identification des parties ré-utilisables. Ainsi, elles sont limitées à identifier des composants, correspondant à des ensembles de classes, permettantl’extraction d’une vue architecturale de l’ancien système. Mais, les composants identifiés ne peuvent pas être implantés avec un modèle concret de composants.Dans cette thèse, nous proposons deux approches pour améliorer la réutilisation des composants extraits, mais aussi faciliter la compréhension de l’architecture sous-jacente. Ainsi, la première approche vise l’identification des interfaces du composant extrait en fonction de ses interactions avec les autres composants. La seconde a pour objectif de rendre possible l’implantation des composants extraits avec un modèle concret de composants. Ceci est fait en utilisant des instances de classes (objets) qui composent les composants extraits pour déduire des instances possibles de composant.L’évaluation des approches proposées par une étude empirique montre que i) l’ensemble des interfaces identifiées correspondent aux différents aspects fonctionnels des composants extraits. ii) et, qu’il est possible d’implanter, dans un modèle concret de composants, les composants extraits sans modifier le comportement de l’application.Reuse is one of the main goals of software engineering. Many concepts and associated mechanisms were proposed to promote the reuse of features offered by the software. Component based software engineering (CBSE) is one of the important approaches which was proposed to increase the software reuse. Thus, several works were conducted in order to restructure legacy systems into component-based ones. Nevertheless, almost all proposed approaches are more targeted for component identification than for the identification of reusable parts. Thus, they are limited to identify components, corresponding to sets of classes, allowing an extraction of the architectural view of the legacy system. But, the identified components can not be easily implemented in a concrete component model.In this thesis, we propose two approaches to improve the reusability of the extracted components and by the way facilitate the comprehension of the underlying architecture. Thus, the first approach aims the identification of the extracted component’s interfaces according to its interactions with the other components. The second one aims to make extracted components implementable within a concrete component model. This is done by using class instances (objects) that compose the extracted components to infer possible component instances.The evaluation of the proposed approaches via an empirical study showed that i) overall the identified interfaces correspond to the different functional aspects of the extracted components. ii) and, that is possible to implement, within a concrete component model, the extracted components without altering the behavior of the application
    corecore